In large enterprises the need for membership lists management is significant. The number of potential applications of such lists is vast. Some example applications are authorization systems that use lists to represent “Role Assignments” or email systems that use lists for the purpose of maintaining a “Mailing List.” The costs, both administrative and performance, associated with use of membership groups are significant. There are two general methods for administration and use of membership groups—static lists and rules-based lists.
Static lists are one method for managing membership lists. A static list is a physical listing of user names. No other attributes of the user are included in a static list. Accessing static lists is inexpensive. To access the list, a simple fetch operation is used. On the other hand, modifications to the list are statically maintained, creating an enormous administration workload to maintain the lists. For example, the membership lists must be individually identified and edited each time an individual is added, deleted, or modified.
For example, if a new employee joins a human resources department in an organization, that new employee is added to several membership groups. The new employee may be added to the “all employee” e-mail list, the “human resource department” e-mail list, the “benefits software” application permission list, the “performance review software” access list, the “compensation software” application permission list, or any number of lists that the organization has created. If this new employee leaves the organization, the employee may need to be removed from all the groups to which he was added. If the employee changes departments within the organization, the employee may need to be removed from some or all of his current lists and added to new lists. The nature of these changes when static membership lists are employed is administratively burdensome.
Rules-based lists are another method for managing membership lists. Memberships of rules-based lists are built each time they are accessed by the execution of one or more rules and are sometimes referred to as dynamic lists. There is no physically stored membership, hence there is no physical list to update and therefore there is no administrative burden of maintaining such lists. For example, the rules are executed to have a new employee added to the membership list. Such a rule can be stated as “all individuals whose manager attribute value directly or indirectly references ManagerA” where ManagerA is the name of the manager of the Human Resources Department.
While rules-based lists offer a significant advantage in administration, the performance costs are a major hindrance to their widespread application. The dynamic nature of these lists mandates that the membership be computed each time the groups are accessed, in contrast, the static nature of static lists allows quick retrievals. Rules-based lists do not persistently store membership, thus, queries such as “return all the roles of User1” become computationally expensive since this requires that the membership of User1 be determined for all rules-based lists.
An additional limitation of the rules-based lists is that it is difficult to provide change notifications to other applications related to the changes in membership of the list without incurring additional computational expenses. Such is the case because the membership is not explicitly administered and hence changes in membership are unknown. Therefore, the membership must be built by executing the rules each time the list is accessed to obtain the most up to date membership.
Such limitations have resulted in restricted use of the rules-based lists. In situations where performance is critical, rules-based lists are not deployed in favor of static lists that are efficient, albeit they require significant effort in terms of administration.
A solution has been provided for a membership lists that provides the management benefits of a rules-based list with the efficient lookup of a static list. An example, method of managing a membership list includes: executing a set of membership rules to create a membership list, caching the created membership list in storage, and updating the membership list cache as and when member objects are modified. An example system for managing membership lists includes a set of rules, a cache, a cache accessing module, a rule modification module, a cache updating module, and a change notification module.